Add management of monitoredPeriod in sim swap for retrieve-date operation #153
Conversation
Add monitoredPeriod attribute management.
🦙 MegaLinter status: ✅ SUCCESS
See detailed report in MegaLinter reports MegaLinter is graciously provided by |
bigludo7
changed the title
bigludo7
changed the title
Make Mega Linter happy
Make megalinter happy
| @@ -208,6 +219,10 @@ components: | |||
| description: Timestamp of latest SIM swap performed. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z) | |||
| nullable: true | |||
| example: "2023-07-03T14:27:08.312+02:00" | |||
| monitoredPeriod: | |||
| type: integer | |||
| description: Timeframe in days for SIM card change supervision for the phone number. It could be valued in the response if the latest SIM swap occurred before this monitored period. | |||
There was a problem hiding this comment.
question: could it make sense to use hours instead of days here, to align this attribute with "maxAge" parameter from the "check" operation?
When I use check operation , maxAge is internally compared to the monitoredPeriod and the API returns a error when maxAge >monitoredPeriod.
From this perspective it could make sense to use same UoM for both.
On the other hand monitoredPeriod represented in hours promises to be a big number.
Would like to hear other opinions here.
There was a problem hiding this comment.
I asked myself same question when i proposed this design. It seems to me that the use of day is more aligned with this attribute meaning and I preferred it that unit consistency across the API.
BTW Thanks @gregory1g for your helpful review :)
There was a problem hiding this comment.
Agree, even be not fully aligned with maxAge, "days" still looks better here.
Improve documentation following @gregory1g suggestion.
|
I need your help on this one @rartych ! |
code/API_definitions/sim-swap.yaml
Outdated
|
|
||
| - If no swap has been performed and the MNO supports unlimited SimSwap monitoring timeframe, the API will return the SIM activation date (the timestamp of the first time that the SIM connected to the network). | ||
|
|
||
| - If the latest SIM swap date (or the activation date if no SIM swap) cannot be communicated due to local regulations (or MNO internal privacy policies) preventing the safekeeping of the information for longer than the stated period, a `null` value will be returned. Optionally, a `monitoredPeriod` could be provided to indicate monitored time frame (in days) supported by the MNO. In this case the response must be treated as "there was no sim swap events during 'monitoredPeriod'. Either the parameter is optional, it is recommended to support it in SimSwap implementations. |
There was a problem hiding this comment.
"there was no sim swap events" -> "there were no sim swap events"?
| @@ -208,6 +219,10 @@ components: | |||
| description: Timestamp of latest SIM swap performed. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z) | |||
| nullable: true | |||
| example: "2023-07-03T14:27:08.312+02:00" | |||
| monitoredPeriod: | |||
| type: integer | |||
| description: Timeframe in days for SIM card change supervision for the phone number. It could be valued in the response if the latest SIM swap occurred before this monitored period. | |||
There was a problem hiding this comment.
Agree, even be not fully aligned with maxAge, "days" still looks better here.
Co-authored-by: Herbert Damker <[email protected]>
was to were in line 35
|
@bigludo7 there seems to be an error in the linting but I don't find what it is |
Yes - It's because I have 'null' in some example. @rartych find the cause but he hasn't yet the resolution. If we did not find it I will remove the example but as we're not particularly on rush we can let some time to Rafal to find a trick. |
Co-authored-by: Fernando Prado Cabrillo <[email protected]>
Update following @rartych guidance to avoid issue
fernandopradocabrillo
added
don't merge
|
@fernandopradocabrillo @gregory1g @QaunainM As we're not preparing the Spring25 release we can move forward on this one. |
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
Add monitoredPeriod attribute management.
Which issue(s) this PR fixes:
Fixes #124
Special notes for reviewers:
Changelog input
Additional documentation
This section can be blank.